在開始這個系列之前,我先講一件發生在我身上的事。

報名鐵人賽之前,我想搞清楚一件事:這個比賽到底能不能用 AI 幫忙寫?

我拿到了一段答案。條列清楚、術語精準、語氣像法條:

禁止純 AI 生成與灌水:嚴禁直接複製貼上 AI 輸出的整篇文章。如果文章被判定為完全由 AI 代筆、缺乏作者個人的分析、觀點、實作或潤飾,將會被視為「惡意灌水」或「不符合原創精神」,主辦單位有權取消完賽與獲獎資格。

看起來完全沒有問題。它知道「惡意灌水」這個詞是官方用語,知道要提「原創精神」,還很貼心地補了一句「引用部分不得超過全文的 1/3」——而這一句是真的,簡章裡確實有。

我按照這段規則,替自己訂了一套很嚴格的工作流程,老老實實跑了兩個星期。

直到某一天我去下載了官方簡章的 PDF,一頁一頁讀。

那些字不在裡面。

簡章第三頁,〈發文規範〉的第一句是這樣寫的:

本競賽可使用生成式人工智慧等新興科技,唯發文內容仍應遵循以下發文規範。

官方明文允許。下面列的紅線只有四條:自創為限不得抄襲、禁止惡意灌水、每篇多於 300 字且引用不逾 1/3、內容應切題且具備專業。沒有任何一條寫「不得由 AI 代筆」。

我不知道那段文字最初從哪裡來。可能是某篇轉述、可能是某個模型生成的摘要,也可能是誰的合理推測被當成事實傳開。我沒辦法追。

但我知道它為什麼騙得過我:

1. 它的格式是對的 —— 條列、粗體標題、分點
2. 它引用的專有名詞是對的 —— 「惡意灌水」確實是官方用語
3. 它夾雜的部分事實是對的 —— 300 字、1/3 引用比例,全部正確
4. 它的語氣是對的 —— 沒有一點不確定,像是照抄下來的

錯的地方被對的地方保護著。

這就是我這 30 天要處理的問題

我是一名 QA(軟體測試工程師),在一間做行銷自動化平台的公司,負責測試環境和正式環境的驗收。

從八月中開始,我在做一件事:替公司做一個知識庫,讓 PM、RD、QA 和新進員工可以問它專案的事。

起因很現實。我們的票卡系統上累積了一百多張票,而其中大多數是 AI 幫忙開的。內容看起來都很完整——有背景、有描述、有驗收條件。

但團隊裡很少人看得懂這張卡到底在做什麼、我要怎麼測試、修改範圍有哪些。

一百多張。人工重寫不可能。

所以我想做一個東西:把散在票卡、專案管理系統、聊天紀錄、會議錄音和程式碼裡的知識,整理成一個能被問的知識庫。三個硬條件:

• 零 API 成本 —— 公司不會為這個付錢
• 資料不出公司 —— 要餵進去的是系統架構、卡片內容、會議決策
• 能長期跑 —— 不能是一次性的 demo

三十天後你會看到它跑在一台沒有獨立顯卡、15.4 GB 記憶體的筆電上,17 秒回一個答案,一毛錢都不花。

但這個系列真正要講的不是那個

如果只是「我做了一個 RAG 問答」,那沒什麼好寫的,網路上一百篇。

我想寫的是開頭那件事的技術版本。

因為在做這個知識庫的過程中,我遇到了完全一樣的狀況——只是這次錯的東西是 AI 幫我寫的,而我是那個有能力查證的人。

我讓 AI 幫我把八十九張票卡統整成十六張「目前版本統整卡」。產出看起來非常好:每張卡都標了對應的 PR 編號、feature flag 名稱、改到哪個 class、哪條路由、影響幾個頁面。

太好了,好到我不安。

所以我做了一件 QA 會做的事:我把那十六張卡拿去對照程式碼,一項一項查。

我查到八處錯誤。其中最嚴重的一張,卡片上寫著「此問題尚未修復,尚未看到對應的 PR 紀錄」——但實際上那兩個問題都已經修好合併了,而且合併日期還早於卡片的更新日期。

還有三個被引用的 PR 編號,在對應的儲存庫裡根本不存在。

同一批卡片裡,關於資安風險的判斷全部正確,包括一個還沒修的授權缺口,以及為什麼要延後修復的技術理由——都跟程式碼現況完全吻合。

對的和錯的,混在一起。而錯的那些附了編號、附了檔名、格式完全正確。

一個剛進公司的新人,沒有任何能力判斷哪幾條是假的。

為什麼是我來做這件事

我不是 AI 工程師。我沒有訓練過模型,這個系列裡也不會有任何一行 fine-tune 的程式碼。

但這個專案的難點從來不是「怎麼讓 AI 回答問題」——那部分現在很容易。

難點是怎麼知道它答錯了。

而這正好是 QA 每天在做的事:不相信輸出、設計會讓系統露出馬腳的輸入、在別人覺得「看起來沒問題」的地方多問一次為什麼。

三十天後我會拿一個實測結果回來:我故意在餵給模型的資料裡混進三條不相關的事實,看它會不會拿去當理由。結果比我預期的有意思——答對的那顆模型,不是比較聰明的那顆。

這 30 天的地圖

而我第一次意識到這件事,比那段假規則更早

那時候我還沒開始做知識庫,只是真的需要一份東西。

看板上的卡太多了。同一個地方被改過好幾輪,前後規格不一致,而且全都還沒上正式版——我需要一份說明書,告訴我現在每個頁面、每項功能的最終版本到底長什麼樣。

所以我請 AI 幫我把整條河道的卡整理成那份說明書。

而且我把規則講得很清楚:以「頁面」為單位拆分。讀完那一百多張卡,判斷每一項功能出現在哪些頁面——如果甲功能出現在第 1、2、3 頁,那這三頁都要各自寫出甲功能,不准偷懶只寫在其中一頁、然後補一句「其他頁也有」。

我當時覺得自己交代得夠仔細了。

它給了我。格式完整、分頁清楚、每一項都寫得斬釘截鐵。

而這份說明書,後來被拿去當成一個新人的測試依據。

他測完,來跟我說:測試結果是失敗。

我沒有直接相信「產品壞了」。我做的第一件事,是把他的測試項目、還有他手上那份 AI 整理出來的卡,一項一項攤開來看,然後回頭去對原始的票卡。

有一部分失敗是真的,產品確實有問題。

但另一部分不是。那幾項失敗的原因,在那份說明書本身:

• 原本在 A 頁面的甲功能,被寫進了 B 頁面——他照著文件跑去 B 頁面找,當然找不到
• 另一條規則,原票卡寫的是「當數量 < 2」,說明書上變成了「< 6」

這兩處都不是憑空生出來的。那個功能真的存在,那個數字也真的在某張卡上出現過。它們只是被放到了錯的位置——而且是在我已經特別交代「每個頁面都要各自寫清楚」之後。

而真正讓我停住的,不是它寫錯了。

是這條錯誤一路走到了一個新人手上,而他完全沒有能力發現它是錯的。

他做了他能做的每一件事:照著文件測、老實回報結果。

而他那幾項 FAIL 是假的——它們描述的不是產品的狀態,是文件的狀態。

更麻煩的是:真的失敗和假的失敗,混在同一份回報裡。 從外面看,它們長得一模一樣。

如果那天他沒有回報,或是我沒有回頭去翻原始票卡,這件事會以「某某功能壞了」的形式被記下來,然後有人會去修一個根本不存在的問題。

當下我沒有想「AI 好爛」。我想的是另一件事,而且那句話從那天之後就沒離開過:

那我沒有回頭去對的那些呢?

最後

我不會在這個系列裡說「AI 不能用」。恰恰相反——這三十天做的每一件事都重度依賴 AI,包括這個知識庫本身。

我想說的是另一件事:

AI 產出的東西不是「會胡說八道」那麼簡單。它是大部分正確、少部分錯得很有說服力。

而那少部分,會被大部分保護著。

就像開頭那段假規則一樣。

明天開始講這個專案的起點:我們有一百多張 AI 幫忙開的票,和一個看不懂它們的團隊。